The result of this PR:

20:15:15.522705/SRT:RcvQ:w1 D:SRT.qr: @812622476: processData: m_pRcvLossList->insert(1571759771 1571759771)
20:15:15.522719/SRT:TsbPd D:SRT.qr: @812622476: dropFromLossLists(): m_pRcvLossList->remove(1571759766, 1571759771)
20:15:15.522753/SRT:RcvQ:w1*E:SRT.qr: RCV-LOSS/insert: IPE: (1571759771,1571759771) to be inserted too small: m_iLargestSeq=1571759771, m_iLength=0, m_iHead=-1, m_iTail=3 -- REJECTING

This log was printed frequently, maybe we should turn down it's level.

@gou4shi1 thank you for this elegant solution!

If the warning message is printed too often, then in addition to this fix, it probably makes sense to find a way to properly synchronize changes to the buffer and loss list. Decreasing log message severity instead will just hide the problem. Will take some time to think. 🤔

Reviewer TODO

• Check this PR conflict neither with packet filter, nor with the packet reorder tolerance logic.

If the warning message is printed too often, then in addition to this fix, it probably makes sense to find a way to properly synchronize changes to the buffer and loss list.

If those debug logs are disabled, this warning message will not be printed frequently, otherwise, #2192 would be very easy to reproduce :)
During debugging, I think CRcvLossList deserves more sanity checks, I will submit more PRs to add checks with __builtin_expect() and unit tests.

nor with the packet reorder tolerance logic.

I have checked the logic of packet reorder tolerance, seq that was dropped by tsbpd may still be inserted into m_FreshLoss, which may result in some useless lossreports, but it should be fine since ack will be updated correctly.